Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-103.txt

Text File | 1994-12-08 | 42.7 KB | 1,053 lines | [TEXT/R*ch]

C.S.M.P. Digest             Thu, 04 Jun 92       Volume 1 : Issue 103

Today's Topics:

    C vs. OOP
    anyone used macrecorder or built-in mic on PB?
    OOP development of GUIs on a Macintosh
    Is AppMaker worth the disks it is distributed on???
    MacinTalk and Voice Synthesis (a missing piece)
    compression/decompression source code wanted
    Decompressing .LZH files?
    Program crashing with TuneUp 1.1.1


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (K. Fischer)
Subject: C vs. OOP
Date: 28 Apr 92 15:58:13 GMT
Organization: LLNL

Hi,
Forgive me if this is a stupid question, but I just purchased Think C
5.0.2 last week
and have been glancing at the OOP stuff -- looks pretty nifty --  BUT
...
I noticed there was no information about the speed of OOP code vs.
'normal'  C.  If I decided to write a program that uses some graphics,
would I be better of (speed wise) using one or the other?

Thanks,
Kathleen

- --
Kathleen Fischer
Lawrence Livermore National Lab
[e-mail]

Disclaimer:  These are my words -- my employer had nothing to do with
them.

"The man who smiles when things go wrong,
 has thought of someone he can blame it on"
                           -- Unknown

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Ulrich Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Tue, 28 Apr 1992 19:08:14 GMT

In article <[e-mail]> [e-mail] (K. Fischer) writes:
>Hi,
>Forgive me if this is a stupid question, but I just purchased Think C
>5.0.2 last week
>and have been glancing at the OOP stuff -- looks pretty nifty --  BUT
>...
>I noticed there was no information about the speed of OOP code vs.
>'normal'  C.  If I decided to write a program that uses some graphics,
>would I be better of (speed wise) using one or the other?

If you are trained in both, you'll probably write the OOP code slightly faster
than the non-OOP one (considerably faster for large programs).

In case your question was about *run time* :-), I'd estimate the cost of an OOP
message call to be less than twice the cost of a normal procedure call, and the
relative cost of these is not that prohibitive to begin with. I wouldn't worry
too much if I were you.

Matthias

- -----
Matthias Neeracher                                   [e-mail]
   "Have you heard of the new Cambridge compilers ? They distribute
    gear-wear much more evenly"
        -- William Gibson/Bruce Sterling, _The Difference Engine_


+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: 30 Apr 92 04:08:26 GMT
Organization: EnigamI, Inc., Nashua, NH


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (K. Fischer) writes:
>Hi,
>Forgive me if this is a stupid question, but I just purchased Think C
>5.0.2 last week
>and have been glancing at the OOP stuff -- looks pretty nifty --  BUT
>I noticed there was no information about the speed of OOP code vs.
>'normal'  C.  If I decided to write a program that uses some graphics,
>would I be better of (speed wise) using one or the other?

I can't say for sure about Think C, as I don't use it.  However, Good
C++ code is usually a smidge faster than good C code.  The reason
for this is that virtual functions are somewhat faster than switch
statements + function calls.

Your development time, and maintenence time should be much reduced,
but your planning / design time should be much longer.  In the end,
oop is a big win in the development time though.  That extra time
spent in planning tends to pay off big time.

HOWEVER, you really need to understand oop to get any benefit out
of it.  It is really a very different style of coding.

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Microsoft Free and Proud Of It!...
                           ...Microsoft Products: Just Say no.

---------------------------

From: [e-mail] (Andrew J. Kass)
Subject: anyone used macrecorder or built-in mic on PB?
Date: 30 Apr 92 20:53:45 GMT
Organization: M.I.T. Media Laboratory

We are having a problem using the MacRecorder on a PB170. When trying to record with SoundEdit 2.0.5 and MacRecorder driver 1.0.2, after clicking the record button, there is no way to stop recording until the time allocated is up. Cmd-opt-esc doesn't even work (which means that keyboard interrupts are disabled for some reason). In addition, when we try recording sound using our own software, the sounds are garbled and have clicks in them.

We are using the MacRecorder because using the built in driver causes the system to hang sometimes when calling SetUpAIFFHeader. Anyone ever heard of that?

Please respond by email. Thanks

Andrew Kass
Speech Research Group
MIT Media Laboratory
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Organization: Helsinki University of Technology, Finland
Date: Fri, 1 May 1992 19:24:46 GMT

In article <[e-mail]> [e-mail] (Andrew J. Kass) writes:
>We are having a problem using the MacRecorder on a PB170. When trying
>to record with SoundEdit 2.0.5 and MacRecorder driver 1.0.2, after
>clicking the record button, there is no way to stop recording until the
>time allocated is up. Cmd-opt-esc doesn't even
>work (which means that keyboard interrupts are disabled for some
>reason). In addition, when we try recording sound using our own
>software, the sounds are garbled and have clicks in them.

The MacRecorder and compatible devices use the serial port for
reading the A/D converted. This means that the CPU has to read
about 176k bps, which is pretty close to LocalTalk speeds. To
read the serial port at that speed, the computer has to stay in
a tight loop with interrupts disabled. So the CPU is just polling
the sound hardware in a busy loop.

I don't have the MacRecorder driver, so I have just been assuming
that it doesn't support asynchronous sound input, because the
interrupt frequency would be incredible and eat up all the CPU
and it still might not work. So, can comeone confirm my guess
that the MacRecorder driver doesn't work asynchronously?

The garbledness and clicks might be because the driver misses
a few samples now and then. It could also indicate a problem
with your software.

The built-in sound input hardware is a totally different beast.
It seems to use a 512 byte in the sound chip. This means that
the CPU only has to process those 512 samples 44 timer per second.
This leaves plenty of time for handling other things.

>We are using the MacRecorder because using the built in driver causes
>the system to hang sometimes when calling SetUpAIFFHeader. Anyone ever
>heard of that?

I haven't used SetUpAIFFHeader. In fact, my program doesn't keep the
sound data around, since it analyzes it in the sound interupt routine.

They must have tested SetUpAIFFHeader and some programs must be using
it, so rather than trying to make the brain-dead MacRecorder work, I
would try to figure out what goes wrong with the internal sound
driver.

   ____________________________________________________________________________
  / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+++++++++++++++++++++++++++

From: [e-mail] (Andrew J. Kass)
Date: 3 May 92 02:00:24 GMT
Organization: M.I.T. Media Laboratory

In article <[e-mail]>, [e-mail] (Juri Munkki) writes:
|> In article <[e-mail]> [e-mail] (Andrew J. Kass) writes:
|> >We are having a problem using the MacRecorder on a PB170. When trying
|> >to record with SoundEdit 2.0.5 and MacRecorder driver 1.0.2, after
|> >clicking the record button, there is no way to stop recording until the
|> >time allocated is up. Cmd-opt-esc doesn't even
|> >work (which means that keyboard interrupts are disabled for some
|> >reason). In addition, when we try recording sound using our own
|> >software, the sounds are garbled and have clicks in them.
|>
|> The MacRecorder and compatible devices use the serial port for
|> reading the A/D converted. This means that the CPU has to read
|> about 176k bps, which is pretty close to LocalTalk speeds. To
|> read the serial port at that speed, the computer has to stay in
|> a tight loop with interrupts disabled. So the CPU is just polling
|> the sound hardware in a busy loop.

Well, this is not true. First of all, the MacRecorder has a 192 byte internal buffer, and secondly, the i/o is buffered. Not to mention that as far as CPU speeds go, 176 bits per sec is EXTREMELY slow... besides, if you try recording with soundedit on anything other than a PowerBook, it works fine (click the mouse any time after you begin recording to stop it). Interrupts are not normally disabled. A 25Mhz processor looks at 176 khz and laughs...

|>
|> I don't have the MacRecorder driver, so I have just been assuming
|> that it doesn't support asynchronous sound input, because the
|> interrupt frequency would be incredible and eat up all the CPU
|> and it still might not work. So, can comeone confirm my guess
|> that the MacRecorder driver doesn't work asynchronously?

The MacRecorder driver itself is not asynchronous. However, the normal macintosh toolbox calls are. Besides, SoundEdit doesn't even work through the drivers I think.. it goes for the serial port or sound chip directly...

|>
|> The garbledness and clicks might be because the driver misses
|> a few samples now and then. It could also indicate a problem
|> with your software.

I have heard of PBs dropping data at speeds over 9600 baud, but this type of distortion doesn't sound like that.

|>
|> The built-in sound input hardware is a totally different beast.
|> It seems to use a 512 byte in the sound chip. This means that
|> the CPU only has to process those 512 samples 44 timer per second.
|> This leaves plenty of time for handling other things.
|>
|> >We are using the MacRecorder because using the built in driver causes
|> >the system to hang sometimes when calling SetUpAIFFHeader. Anyone ever
|> >heard of that?
|>
|> I haven't used SetUpAIFFHeader. In fact, my program doesn't keep the
|> sound data around, since it analyzes it in the sound interupt routine.
|>
|> They must have tested SetUpAIFFHeader and some programs must be using
|> it, so rather than trying to make the brain-dead MacRecorder work, I
|> would try to figure out what goes wrong with the internal sound
|> driver.
|>

We already sent a letter to Apple DTS telling them about the problem, along with a small segment of code that demonstrates the problem. I was just wondering if anyone else has seen or heard of anything like this. Believe me, we have no desire or intention of continuing to use the MacRecorder... we just can't use the built in if SetUpAIFF fails...

|>    ____________________________________________________________________________
|>   / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
|>  / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
|>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Andrew Kass
Speech Research Group
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Date: 3 May 92 18:28:52 GMT
Organization: Helsinki University of Technology, Finland

In article <[e-mail]> [e-mail] (Andrew J. Kass) writes:
>Well, this is not true. First of all, the MacRecorder has a 192 byte
>internal buffer, and secondly, the i/o is buffered. Not to mention that
>as far as CPU speeds go, 176 bits per sec is EXTREMELY slow... besides,
>if you try recording with soundedit on any thing other than a
>PowerBook, it works fine (click the mouse any time after you begin
>recording to stop it). Interrupts are not normally disabled. A 25Mhz
>processor looks at 176 khz and laughs...  >

All the MacRecorder code that I have ever seen switches off interrupts
and runs in a tight loop. This might be because the MacRecorder is
compatible with older devices like the MacNifty and SID-variants.
These older devices don't have any internal buffering, since they
are basically serial A/D-converters. Even the bits come out reversed
(LSB first).

If a 25Mhz processor laughs at 176khz, then why does LocalTalk have
to receive data a packet at a time in a loop that disables interrupts?

I wrote:
>|> I don't have the MacRecorder driver, so I have just been assuming
>|> that it doesn't support asynchronous sound input, because the
>|> interrupt frequency would be incredible and eat up all the CPU
>|> and it still might not work. So, can comeone confirm my guess
>|> that the MacRecorder driver doesn't work asynchronously?
>
>The MacRecorder driver itself is not asynchronous. However, the normal
>macintosh toolbox calls are. Besides, SoundEdit doesn't even work
>through the drivers I think.. it goes for the serial port or sound chip
>directly...

So what are you saying? I'm talking about the System 7.0 sound recording
calls as documented in Inside Macintosh VI. SoundEdit has nothing to do
with this. I don't think that SoundEdit would be so badly written that
it would use the sound chip directly. The older versions certainly use
the serial port directly, since that was the only way to input sound.
Of course there's no way to use the serial driver to input sounds.

My question was and still is: There's a System 7.0 compatible sound
input driver for the MacRecorder. Does it support asynchronous recording?
The first sentence makes sense to me, but why do you then write about
toolbox calls and SoundEdit. This has nothing to do with them.

>|> The garbledness and clicks might be because the driver misses
>|> a few samples now and then. It could also indicate a problem
>|> with your software.
>
>I have heard of PBs dropping data at speeds over 9600 baud, but this
>type of distortion doesn't sound like that.

The PB140/170 data dropping is caused by the power saver that disables
interrupts. At 9600 bps, about 20-30 characters are lost. At the speeds
at which the serial sound input devices are read, potentially 20 times
more data will be lost (unless the MacRecorder holds it in its internal
buffer, of which I have never heard before).

>We already sent a letter to Apple DTS telling them about the problem,
>along with a small segment of code that demonstrates the problem. I was
>just wondering if anyone else has seen or heard of anything like this.
>Believe me, we have no desire or intention of continuing to use the
>MacRecorder... we just can't use the built in if SetUpAIFF fails...

I'm sorry to have wasted your time. I'm sorry I wasted my time giving
you some kind of answer.

You could also try to learn to hit return now and then. I hate to waste
my time formatting other people's articles. Not all of us have screens
that are 256 characters wide.

   ____________________________________________________________________________
  / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------

From: [e-mail] (David M Geary)
Subject: OOP development of GUIs on a Macintosh
Date: 22 Apr 92 17:36:03 GMT
Organization: Boeing Aerospace & Electronics


NOTE:  Please respond via email - our newsfeed is way behind.
       Thanks.

  I may soon have the opportunity to develop a GUI on a Mac.
I would much prefer to use an OOP language, but I have no
idea what is available on the Mac.  Some questions:

1.  What are my choices concerning C++?

2.  Are there any GUI "builders", such as those that exist for X
    for the MAC.

3.  Are there any C++ class libraries available for GUIs?

4.  What about smalltalk?

  I realize that smalltalk would probably be the easiest way to
get an OOP GUI up and running, but it may not be Politically
Correct to do so.  Therefore, I am interested in hearing about
the possibilities of using C++.


- --
|...............  David Geary, Boeing Aerospace, Seattle, WA. ................|
|-----------------------------------------------------------------------------|
|     Seattle:  America's most attractive city   ...   to the *jetstream*     |
|-----------------------------------------------------------------------------|

+++++++++++++++++++++++++++

From: [e-mail] (Sean Hall - CS460)
Date: 23 Apr 92 05:23:23 GMT
Organization: Washington State University

In article <[e-mail]> [e-mail] (David M Geary) writes:
>
>NOTE:  Please respond via email - our newsfeed is way behind.
>       Thanks.
>
>  I may soon have the opportunity to develop a GUI on a Mac.
>I would much prefer to use an OOP language, but I have no
>idea what is available on the Mac.  Some questions:
>
>1.  What are my choices concerning C++?
>
>2.  Are there any GUI "builders", such as those that exist for X
>    for the MAC.
>
>3.  Are there any C++ class libraries available for GUIs?
>
>4.  What about smalltalk?
>
>  I realize that smalltalk would probably be the easiest way to
>get an OOP GUI up and running, but it may not be Politically
>Correct to do so.  Therefore, I am interested in hearing about
>the possibilities of using C++.

   So what you are really asking is if an OOP GUI is PC and should it
   be done in C++, TCL or MPW?  Sounds like youve been working on
   military projects too long. (:\>
>
>
>--
>|...............  David Geary, Boeing Aerospace, Seattle, WA. ................|
>|-----------------------------------------------------------------------------|
>|     Seattle:  America's most attractive city   ...   to the *jetstream*     |
>|-----------------------------------------------------------------------------|

+++++++++++++++++++++++++++

From: [e-mail] (Stu Schaffner)
Organization: MITRE Corp.
Date: Thu, 23 Apr 1992 16:22:12 GMT

In article <[e-mail]>, [e-mail] (David M Geary) writes:
>
>
> NOTE:  Please respond via email - our newsfeed is way behind.
>        Thanks.
>
>   I may soon have the opportunity to develop a GUI on a Mac.
> I would much prefer to use an OOP language, but I have no
> idea what is available on the Mac.  Some questions:
>
> 1.  What are my choices concerning C++?
>
> 2.  Are there any GUI "builders", such as those that exist for X
>     for the MAC.
>
> 3.  Are there any C++ class libraries available for GUIs?
>
> 4.  What about smalltalk?
>

Take a good look at MacApp.  It is an object-oriented application framework
with C++ and Object Pascal bindings. IMHO it makes most GUI builders for
X Windows look pretty pathetic, or at least pretty overpriced. Couple it
with MPW, the ObjectMaster class-browser/structured-editor from ACIUS, and
with the IcePick widget layout tool from KPMG.EXIS and you have an interesting
development system. MacApp is an Apple product and is being used to build
a large number of industrial-strength products both within Apple and by
outside commercial enterprises. A port to MS Windows is promised soon.

As for Political Correctness, let's face it:  none of these languages
are Ada!  Seriously, not only are there good SmallTalk systems available
for the Mac, but there is a CLOS system that is reputed to be good. A lot
of the Apple research mavens use it.

Stu Schaffner, not speaking for
The MITRE Corp.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dakin)
Organization: Oceania Health Care Systems
Date: Thu, 23 Apr 92 16:22:12 GMT

In article <[e-mail]> [e-mail] (David M Geary)
writes:

>   I may soon have the opportunity to develop a GUI on a Mac.
> I would much prefer to use an OOP language, but I have no
> idea what is available on the Mac.  Some questions:
>
> 1.  What are my choices concerning C++?
>
> 2.  Are there any GUI "builders", such as those that exist for X
>     for the MAC.
>
> 3.  Are there any C++ class libraries available for GUIs?
>
> 4.  What about smalltalk?
>
>   I realize that smalltalk would probably be the easiest way to
> get an OOP GUI up and running, but it may not be Politically
> Correct to do so.  Therefore, I am interested in hearing about
> the possibilities of using C++.

Well, this response doesn't exactly answer your questions about C++, but I'd
like to suggest that you check out Objective-C for the Mac.  It is a 100%
object-oriented C language (unlike C++) based on Smalltalk.  I have found it be
the most elegant, and easy to use object oriented language I have tried (and
I've tried many).  If you want more info, call Sarah Bell at Stepstone.  Her
number is: 1-800-289-6253.

I am currently working on a set of GUI objects in Objective-C that I plan to
use in all my future programs.

NOTE: I am in no way affiliated with Stepstone other than a very satisfied
customer.

Steve

+++++++++++++++++++++++++++

From: [e-mail] (Eric W. Sink)
Organization: University of Illinois at Urbana-Champaign
Date: Thu, 23 Apr 1992 18:19:00 GMT

In <[e-mail]> [e-mail] (Steve Dakin) writes:

>Well, this response doesn't exactly answer your questions about C++, but I'd
>like to suggest that you check out Objective-C for the Mac.  It is a 100%
>object-oriented C language (unlike C++) based on Smalltalk.

This is ridiculous.  I like Objective-C a lot myself, but:

1.  "100% object-oriented C language" is a contradiction in terms
2.  There is nothing any more object-oriented about Objective-C than
    C++.
3.  Saying that Objective-C is 100% object oriented is blatantly incorrect,
    not to mention ill-defined.

- --
Eric W. Sink, USACERL         | The essence of GUI programming : "What
Box 9005, Champaign, IL       | started out as a half hour hack has been
61826-9005 1-800-USA-CERLx449 | bothering me for two weeks now." -- Matt Mora
- ---- [e-mail] ---------|

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 26 Apr 92 00:40:08 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Stu
Schaffner) writes:
> As for Political Correctness, let's face it:  none of these languages
> are Ada!  Seriously, not only are there good SmallTalk systems available
> for the Mac, but there is a CLOS system that is reputed to be good. A lot
> of the Apple research mavens use it.

Yes, Macintosh Common Lisp is $495, and that's really cheap for a full
Common Lisp implementation with CLOS (not all of MOP is yet supported),
as well as CLOS class libraries for some of the MacOS managers.

And yes, Apple Advanced Reseach uses MCL a lot for prototyping of their
wildest ideas.

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 26 Apr 92 00:42:05 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Eric W.
Sink) writes:
>
> In <[e-mail]> [e-mail] (Steve Dakin) writes:
>
> >Well, this response doesn't exactly answer your questions about C++, but I'd

> >like to suggest that you check out Objective-C for the Mac.  It is a 100%
> >object-oriented C language (unlike C++) based on Smalltalk.
>
> This is ridiculous.  I like Objective-C a lot myself, but:
>
> 1.  "100% object-oriented C language" is a contradiction in terms
> 2.  There is nothing any more object-oriented about Objective-C than
>     C++.
> 3.  Saying that Objective-C is 100% object oriented is blatantly incorrect,
>     not to mention ill-defined.

Objective C does have dynamic binding, but as Eric stated, it's hard
nowdays to define what OOP is exactly. Objects-in-C also provides dynamic
binding, and why not take the step to SmallTalk/CLOS for a pure dynamic
environment?

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Andrew Loewenstern)
Date: 28 Apr 92 02:24:50 GMT
Organization: Cube Technologies, Inc.

In article <[e-mail]> [e-mail] writes:
>In <[e-mail]> [e-mail] (Steve Dakin) writes:
>
>>Well, this response doesn't exactly answer your questions about C++, but I'd
>>like to suggest that you check out Objective-C for the Mac.  It is a 100%
>>object-oriented C language (unlike C++) based on Smalltalk.
>
>This is ridiculous.  I like Objective-C a lot myself, but:
>
>1.  "100% object-oriented C language" is a contradiction in terms
>2.  There is nothing any more object-oriented about Objective-C than
>    C++.
>3.  Saying that Objective-C is 100% object oriented is blatantly incorrect,
>    not to mention ill-defined.

Objective-C offers runtime binding instead of C++'s static binding.  I
use Obj-C on a NeXT and I'd kill myself without it.  Also, Objective-C
is much much less complex and easier to use than C++.

The only OOP feature that Obj-C doesn't offer is
multiple-inheiritance.  However, you can get around that with posing
if you'd like.  I find it hard to classify C++ as a true OO language
if it can't support runtime binding of objects.  Without that one
feature you miss half of what OOP is all about.  If you don't think
runtime binding is important or good, take a look at NeXT's Interface
Builder (particularly the one in NeXTSTEP 3.0...).  Then take a look a
UIM/X or any of the awful IBs for X from companies like Solbourne and
IBM...

What's really funny is that C++'s complexity makes it difficult to
reap the other benefit of OOP; easier development and maintinence of
code.

Stepstone's product is excellent...  Also, gcc-2.0 has objective-c.
As soon as the FSF finishes the runtime environment, it will be a good
(free) alternative to Stepstone.  However, Stepstone's class library
is pretty good (I really like the list class).


andrew
- --
[e-mail]
Andrew Loewenstern            |  "listen: there's a hell of a good universe
Cube Technologies, Inc.       |   next door; let's go." --- e.e. cummings

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 28 Apr 92 23:08:32 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Andrew
Loewenstern) wrote:
>
> Objective-C offers runtime binding instead of C++'s static binding.  I

I think this terminology is confusing.  C++ has virtual method calls that are
resolved dynamically at runtime.

Correct me if I'm wrong, but what Objective-C (as well as Smalltalk, CLOS, ...)
has is untyped objects, which lets you send any message you want to an object.
Because there's no compile-time type checking, it's possible that the object
will not understand the message.

The compile-time type checking also allows you to optimize the method
dispatching a bit over what's available in Objective-C.  I think Objective-C
also supports typed objects, which should be very similar to C++'s objects.

If you look at MacApp, you'll see that it's possible to read and write objects
to a stream, and with the dynamic linker facility that's in development (Dinker)
you can add to classes to a program while it is running.

> if you'd like.  I find it hard to classify C++ as a true OO language

There's always a debate about this.  If you accept Peter Wegner's definition of
OO language, then C++ qualifies.

- -----
Larry Rosenstein
Taligent, Inc.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dakin)
Date: 1 May 92 22:08:09 GMT
Organization: Oceania Health Care Systems

Let me begin by apologizing to Eric for calling Objective-C 100% object
oriented.  I should have been much more conservative in such a touchy subject
area.

In article <[e-mail]> [e-mail] (Larry Rosenstein) writes:
> Correct me if I'm wrong, but what Objective-C (as well as Smalltalk, CLOS...)
> has is untyped objects, which lets you send any message you want to an
> object.  Because there's no compile-time type checking, it's possible that
> the object will not understand the message.

This is true.  To get around the problem of sending a message to an object that
doesn't respond to it, Objective-C offers the resondsTo: method which tells you
whether an object supports a particular method.

> The compile-time type checking also allows you to optimize the method
> dispatching a bit over what's available in Objective-C.  I think Objective-C
> also supports typed objects, which should be very similar to C++'s objects.

If you specifically type an object in Objective-C, the compiler WILL inform you
if you try to send a message to an object that doesn't respond to it.

happy OOCing,

Steve

+++++++++++++++++++++++++++

From: [e-mail] (Andrew Loewenstern)
Date: 1 May 92 03:23:40 GMT
Organization: Cube Technologies, Inc.

In article <[e-mail]> [e-mail] (Larry Rosenstein) writes:

>Correct me if I'm wrong, but what Objective-C (as well as Smalltalk, CLOS, ..)
>has is untyped objects, which lets you send any message you want to an object
>Because there's no compile-time type checking, it's possible that the object
>will not understand the message.
>
>The compile-time type checking also allows you to optimize the method
>dispatching a bit over what's available in Objective-C.  I think Objective-C
>also supports typed objects, which should be very similar to C++'s objects.

Well, generally you use a generic type for objects called "id"  But
you can use the type <classname>* for more robust type checking at
compile-time.  I believe the the method lookup is still dynamic.

Objective-C's method dispatching isn't all that slow and if you need
to call a method really really quickly in say a tight loop, you can
get the actual function before you enter the loop to reduce the
overehead.  NeXT has optimized the hell out of it though... If I
remember correctly, they have gotten the message overhead to something
like 7 instructions in NeXTSTEP 3.0.  Fairly impressive.  I'm not
quite sure what the overhead is on Stepstone's Macintosh version.
Probably no more than three times that of a normal c function-call.


andrew
- --
[e-mail]
Andrew Loewenstern            |  "listen: there's a hell of a good universe
Cube Technologies, Inc.       |   next door; let's go." --- e.e. cummings

---------------------------

From: [e-mail] (Curt Stevens)
Subject: Is AppMaker worth the disks it is distributed on???
Date: 29 Apr 92 15:44:36 GMT
Organization: University of Colorado, Boulder


I have been developing using Macintish CommonLisp for some time and I
will now be doing some Think C development. I was looking for tools to
help development and I heard about AppMaker. Is this any good? Doe sit
save any time? Does anyone use it? Are you laughing at me right now?

Thanks very much for any help and any additional information you can
supply me with.

========================================================================
|Curt Stevens   [phone] | / |arpa:[e-mail]  |
|Univ. of Colorado, Boulder    |o o|uucp:ncar!sigi.cs.colorado.edu!... |
|Computer Sci. Dept. ECOT 7-7  | | |-----------------------------------|
|Campus Box 430                |\_/| I contradict myself? Very well, I |
|Boulder, Colorado 80309  USA  |   | contradict myself. - Walt Whitman |
========================================================================
- --

========
| Curt |
========

+++++++++++++++++++++++++++

From: [e-mail] (Andrew Dent)
Organization: DIALix Services, Perth, Western Australia
Date: Sat, 02 May 92 11:40:56 GMT

I'm an AppMaker fan, particularly if you want to use the Think Class
Library and also if you have complex screens.

It generates VERY nice code for multiple environments but TCL-based code
is a lot easier for re-generation of code if you change things a lot (due
to the separation of functions inherent in TCL vs procedural programming).


I've also got MarksMan which has superior screen drawing and more screen
objects but generates horrible code from an OOP point of view (it fails
to use the TCL DoCommand hierarchy, for example).

AppMaker is completely template driven with a full template language so
you can also customise its output.

Andy Dent (A.D. Software - Mac & VAX programming)
94 Bermuda Dve, BALLAJURA  Western Australia  6066
Phone/Fax: [phone] (local)  [phone] (International)
       Internet: [e-mail]    Compuserve: 100033,3241


+++++++++++++++++++++++++++

From: [e-mail] (Terry Thiel)
Date: 2 May 92 13:10:11 GMT
Organization: University of Illinois at Urbana

Just for info you can buy Appmakers for an educational price of $149.
Call Bowers Development at [phone] for details.  I think the average mail
order price is $214 and the retail is $295.  I faxed them a purcahse oryMder and they shipped it the same day overnight mail.  Haven't looked at it yet so
I can't give you any impressions of the product.  All the reviews I saw said
it was the best one to get though.
- -Terry

---------------------------

From: [e-mail] (Bob Pizzi)
Subject: MacinTalk and Voice Synthesis (a missing piece)
Date: 1 May 92 04:40:02 GMT

..(cross posted in *.mac.system)..

In terms of Apple supporting system software across machines, they do a good
job (IMHO), however, MacinTalk is not one of them.

According to my latest copy of APDA, Macintalk development package is
a Class 3 restricted product.  As I interpret that, Apple does not want
*us* developing any apps that use the Macintalk interface.  Is that *your*
interpretation as well?

If, then Apple does not want MacinTalk perpetuated, is there a third
party voice synthesis driver (MPW interface to it would be nice) that
can be licenced??

I am writing up a proposal for development of an app for use with
the visually impaired, and voice has been requested.  I am reluctant
to use MacinTalk, and I am looking for alternatives.

- ------------------------------------------------------------------------------
Bob Pizzi            | "Show skill..is as close as we got to that ultimate
UC-Irvine            | mystery. I throw death aside. Death is not mysterious"
Undergrad-ICS        |                 -- Katherine Dunn  "Geek Love"
- ------------------------------------------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Andrew J. Kass)
Organization: M.I.T. Media Laboratory
Date: Sun, 3 May 1992 02:17:28 GMT

In article <[e-mail]>, [e-mail] (Bob Pizzi) writes:
|> ..(cross posted in *.mac.system)..
|>
|> In terms of Apple supporting system software across machines, they do a good
|> job (IMHO), however, MacinTalk is not one of them.
|>
|> According to my latest copy of APDA, Macintalk development package is
|> a Class 3 restricted product.  As I interpret that, Apple does not want
|> *us* developing any apps that use the Macintalk interface.  Is that *your*
|> interpretation as well?
|>
|> If, then Apple does not want MacinTalk perpetuated, is there a third
|> party voice synthesis driver (MPW interface to it would be nice) that
|> can be licenced??
|>
|> I am writing up a proposal for development of an app for use with
|> the visually impaired, and voice has been requested.  I am reluctant
|> to use MacinTalk, and I am looking for alternatives.
|>
|> ------------------------------------------------------------------------------
|> Bob Pizzi            | "Show skill..is as close as we got to that ultimate
|> UC-Irvine            | mystery. I throw death aside. Death is not mysterious"
|> Undergrad-ICS        |                 -- Katherine Dunn  "Geek Love"
|> ------------------------------------------------------------------------------

Apple is almost ready to release (read wait a while) the.... long awaited TTS manager!! This is a replacement for MacinTalk. The problem was, Apple needed something fast for text to speech when the mac first came out. So they licensed this thing called MacinTalk from another company. The problem was, they licensed the binaries, not the code. So it could never be updated. Its a miracle it still even works! Apple has been working on its own version for quite a while. It sounds better than Macintalk, bu



quite as good as.. say a DecTalk. But it has that ability to speak different languages and use different voices. It's actually a very nice product.

Andrew Kass
Speech Research Group
[e-mail]

---------------------------

From: [e-mail] (Paul G. Smith)
Subject: compression/decompression source code wanted
Date: 30 Apr 92 14:37:01 GMT
Organization: CommsTalk HQ

Hi folks,

Can anyone point me towards some example source code for compression/
decompression of data? Preferably, an example of Lempel-Ziv that is in the
public domain and free for modification and experimentation (the data I
am fiddling with is not suitable for simple schemes like RLL encoding).

I don't have FTP access at present, btw.

best regards, Paul

- -------------------------------------
Paul G Smith / CommsTalk HQ
INTERNET:  "[e-mail]"            CIX:  "pgsmith"
AppleLink: "commstalk.hq" ("[e-mail]")
tel/fax:   + 44 491 574295  (dial 11 on 2nd dial tone for fax)
snail:    40 St Marks Road, Henley-on-Thames, Oxon. RG9 1LW. UK

+++++++++++++++++++++++++++

From: [e-mail] (Syam Gadde)
Date: 30 Apr 92 17:37:19 GMT
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158

Me, too.

Thanks,
    -Syam

---------------------------

From: [e-mail] (Simon K. Train)
Subject: Decompressing .LZH files?
Date: 30 Apr 92 12:42:57 GMT
Organization: Glasgow University Computing Science Dept.

Help me,

 Is there a Mac utility to decompress '.lzh' files? By '.lzh', I
refer to Amiga compression type thingies.
 Thanks (in advance).

 Sims

- ---------------------
Simon Train
[e-mail]
- ---------------------

+++++++++++++++++++++++++++

From: [e-mail] (Shigeo Suwa)
Date: 1 May 92 01:22:45 GMT
Organization: Nomura Research Institute, Ltd.

In article <[e-mail]> [e-mail] (Simon K. Train) writes:

> Is there a Mac utility to decompress '.lzh' files? By '.lzh', I
>refer to Amiga compression type thingies.

You can decompress '.lzh' files with MacLHA 2.00.
MacLHA 2.00 was written by Mr. Kazuaki Ishizaki and it is found on
BMUG's PD-ROM version A1 ("PD-ROM A1:Telcom:Compacting Programs:" folder).
- --
Shigeo Suwa ([e-mail])
MIX:ssuwa   CompuServe:74100,350   NIFTY:PBA00350

+++++++++++++++++++++++++++

From: [e-mail] (Takeshi Miyazaki)
Date: 1 May 92 16:29:13 GMT
Organization: Princeton University

In article <[e-mail]> [e-mail] (Shigeo Suwa) writes:
>You can decompress '.lzh' files with MacLHA 2.00.
>MacLHA 2.00 was written by Mr. Kazuaki Ishizaki and it is found on
>BMUG's PD-ROM version A1 ("PD-ROM A1:Telcom:Compacting Programs:" folder).

And also in sumex (probably util directory) and mac.archive.umich.edu
(in mac/utilities/compressionapp directory.)

- --
Takeshi Miyazaki ([e-mail])

---------------------------

From: [e-mail] (Mike Cote)
Subject: Program crashing with TuneUp 1.1.1
Date: 30 Apr 92 16:18:27 GMT
Organization: Stratus Computer, Inc.

I'm hoping that somebody reading this will be able to give me some direction to
look in to find a particularly nasty bug.  I have a program that runs fine under
System 6.0.7 and System 7.0 however under 7.0 with TuneUp 1.1.1 it crashes/hangs.

Tracking the crash down with Think-C and MacsBug I found that a call to CopyBits
was writing all over memory.  I tried eyeballing all the parameters to CopyBits
and they seem fine.  I thought that perhaps the heap was getting corrupted
earlier but Macsbug says the heap is fine (using HC).

Anyone care to give an opinion on what might be happening?  I'm looking for
anything that will get me looking in the right direction.

Thanks.

mpac

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 1 May 92 05:41:49 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Mike Cote) writes:
> I'm hoping that somebody reading this will be able to give me some direction to
> look in to find a particularly nasty bug.  I have a program that runs fine under
> System 6.0.7 and System 7.0 however under 7.0 with TuneUp 1.1.1 it crashes/hangs.
>
> Tracking the crash down with Think-C and MacsBug I found that a call to CopyBits
> was writing all over memory.  I tried eyeballing all the parameters to CopyBits
> and they seem fine.  I thought that perhaps the heap was getting corrupted
> earlier but Macsbug says the heap is fine (using HC).

My first instinct, when getting QuickDraw crashes, is to check that the
current GDevice is set correctly for drawing into the current port. I've had
some total freezeups through forgetting to do this. Are you doing off-screen
drawing, by any chance? If you're not, then this isn't the reason...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

---------------------------

End of C.S.M.P. Digest
**********************